feat: "waiting" status for threads with open background tasks (i.e. pr monitors) by t3dotgg · Pull Request #4415 · pingdotgg/t3code

t3dotgg · 2026-07-24T01:12:04Z

When the agent stops while background tasks (subagents, background bash, monitors) are still running, the sidebar showed Done, then flicked back to Working when a task completion woke the agent (median 13s later, from local history).

Now ingestion tracks provider-reported open tasks per thread and parks the session on the previously-unused idle status when a turn ends with tasks still open. Sidebar v2 (web + mobile) renders it as a grey Waiting label with the same elapsed timer as Working; the row recedes like other in-flight states. Waiting flips directly to Working on wake-up — no intermediate Done.

Task set is keyed by provider instance and cleared on exit/stop/error, so stale tasks can't park a fresh session.
idle was already handled as "resting" by settlement, projection, and phase logic, so no contract or migration changes; old clients degrade to today's behavior.
Codex/OpenCode don't emit task events — behavior unchanged there.

🤖 Generated with Claude Code

Note

Medium Risk
Changes core session lifecycle in ProviderRuntimeIngestion (when threads show ready vs idle), with broad integration tests but no contract migration—incorrect task tracking could mislabel thread state across clients.

Overview
Threads that finish a turn while provider background tasks (monitors, subagents, etc.) are still open no longer flash Done before the wake-up turn. Provider runtime ingestion now tracks open tasks per thread and provider instance and parks the session on idle instead of ready when a turn ends with tasks still open; task state is cleared on session exit, error, and stale-instance guards, with tombstones for late events.

Web sidebar v2 and the mobile thread list map idle to a muted Waiting label (same elapsed timer as Working, in-flight row treatment). Successful task completion is expected to wake the agent without an intermediate ready; only a stopped last task returns Waiting to ready.

^{Reviewed by Cursor Bugbot for commit 368e0e1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add 'waiting' status for threads with open background tasks

Introduces a new idle session status that signals a thread is waiting on background tasks (e.g. PR monitors) rather than active user input or processing.
ProviderRuntimeIngestion tracks open tasks per thread/provider instance and transitions sessions to idle at rest when tasks remain open, returning to ready when the last task completes.
The web sidebar and mobile thread list both render idle sessions as 'Waiting' with a neutral style and an elapsed duration, treated as in-flight for display purposes.
Open task state is cleared on session exit or error so future sessions do not inherit the waiting state.
Behavioral Change: threads that previously resolved to ready while background tasks were open will now show as waiting until those tasks complete.

^{Macroscope summarized 368e0e1.}

coderabbitai · 2026-07-24T01:12:12Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 91fb2c98-8548-4670-a2cd-2cbb6e8a3eee

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch t3code/sidebar-waiting-state

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-07-24T01:16:45Z

Approvability

Verdict: Needs human review

New feature introducing a 'waiting' status with non-trivial server-side state tracking logic for background tasks. While well-tested, new user-facing behavior and runtime session status changes warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

When the agent stops with background tasks (subagents, background bash, monitors) still running, the thread showed Done, then flicked back to Working when a task completion woke the agent. Track provider-reported open tasks in ingestion and park the session on the previously-unused "idle" status; sidebar v2 renders it as a grey "Waiting" with the same elapsed timer as Working. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Review fixes: gate the terminal-status task sweep behind the lifecycle guard so rejected stale events cannot erase the active turn's tasks; ignore task starts from a provider instance that doesn't match the projected session instead of letting them displace the current set; tombstone completed task ids so late/duplicate progress cannot re-open a finished task and park the thread on Waiting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A completed/failed final task wakes the agent (its notification is the wake signal), so Waiting flips straight to Working. A stopped final task is a kill — no wake follows — and previously left a live session parked on Waiting until teardown. Flip that case back to ready, and tombstone completions that outrun their start event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 514fccf. Configure here.}

Tombstones exist to stop late/duplicate progress from resurrecting a finished task, but providers reuse task ids when an agent is resumed — a fresh task.started after completion is real work, not a replay. Progress stays blocked by the tombstone; an explicit start clears it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Real-data feedback round two: - Results render as a responsive grid (1/2/3 columns) instead of a full-width list. - While the sweep runs, the page shows only a progress count ("Reviewing your work — 7 of 18"); results reveal all at once when every thread is done, so triage happens in one pass over a stable layout instead of chasing cards as they pop in. - The model now returns a one-sentence imperative nextStep ("Review and merge PR #4415.") which becomes the card body — a direct answer to "what should I do here". Summaries are capped at one sentence and demoted to an info-icon tooltip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…2.1-next Absorb CTM tip 408efa6 (Claude replay cleanup, ACP auth/fork provenance, derived-thread wake, fork-shell navigation wait) onto the pingdotgg#4415 Waiting sequence pinned at main ece0508. Conflict resolution (same intent as prior merge 616da6976): - Sidebar/threadList Waiting uses runtime.idle (CTM/orchestrator-v2 park) rather than session.idle from main pingdotgg#4415, including mobile tests. - Drop ProviderRuntimeIngestion (deleted on CTM; v2 uses orchestration-v2).

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

…here resolveThreadListV2Status gains its "waiting" state from pingdotgg#4415 waiting-presentation, Theo's unmerged main-side branch, which is carried only on trial/orchestrator-v2.1. This line pins main to exactly the main CTM contains, so the rule is absent and the assertion cannot hold. This is the only commit unique to orchestrator-v2. Everything below it is the same stack trial/orchestrator-v2.1 carries, replayed onto CTM unchanged, so the two lines differ by pingdotgg#4415 waiting-presentation's four commits and this one adapter.

Update sidebar and mobile expectations for the pingdotgg#4415 Waiting status, repair command-suite settle/interrupt coverage after layer merges, and remove a duplicate settledAt JSON field that broke contracts typecheck.

github-actions Bot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Jul 24, 2026

macroscopeapp Bot reviewed Jul 24, 2026

View reviewed changes

Comment thread apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

Comment thread apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

cursor Bot reviewed Jul 24, 2026

View reviewed changes

Comment thread apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts Outdated

Comment thread apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

t3dotgg changed the title ~~Show Waiting state for threads with open background tasks~~ feat: "waiting" status for threads with open background tasks (i.e. pr monitors) Jul 24, 2026

t3dotgg and others added 2 commits July 23, 2026 22:21

t3dotgg force-pushed the t3code/sidebar-waiting-state branch from bec6dc6 to 528adb2 Compare July 24, 2026 05:22

macroscopeapp Bot reviewed Jul 24, 2026

View reviewed changes

Comment thread apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

cursor Bot reviewed Jul 24, 2026

View reviewed changes

Comment thread apps/web/src/components/SidebarV2.tsx

cursor Bot reviewed Jul 24, 2026

View reviewed changes

Comment thread apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts

mwolson mentioned this pull request Jul 24, 2026

feat(orchestrator): Surface waiting background work #4378

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat: "waiting" status for threads with open background tasks (i.e. pr monitors)#4415

feat: "waiting" status for threads with open background tasks (i.e. pr monitors)#4415
t3dotgg wants to merge 4 commits into
mainfrom
t3code/sidebar-waiting-state

t3dotgg commented Jul 24, 2026 •

edited by macroscopeapp Bot

Loading

Uh oh!

coderabbitai Bot commented Jul 24, 2026 •

edited

Loading

Review skipped

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

macroscopeapp Bot commented Jul 24, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

cursor Bot left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

t3dotgg commented Jul 24, 2026 • edited by macroscopeapp Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Add 'waiting' status for threads with open background tasks

Uh oh!

coderabbitai Bot commented Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

macroscopeapp Bot commented Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Approvability

Uh oh!

Uh oh!

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

t3dotgg commented Jul 24, 2026 •

edited by macroscopeapp Bot

Loading

coderabbitai Bot commented Jul 24, 2026 •

edited

Loading

macroscopeapp Bot commented Jul 24, 2026 •

edited

Loading